The design of bus architectures typically include a number of compromises to optimize performance parameters that may be inversely related to one another. Certain bus architecture standards are designed as open standards to provide a general framework, yet provide flexibility so that certain performance criteria may be enhanced for specific system applications. Futurebus+ is one such open standard. The Futurebus+ standard is an IEEE specification #896.1-1991 and is described in an article entitled "Futurebus+ Coming of Age" (Theus, John, "Futurebus+ Coming of Age", Microprocessor Report, May 27, 1992, pp. 17-22).
The Futurebus+ architecture standard allows two operating speeds, a fully compelled mode and a source synchronous packet mode. Packet mode, the highest speed of operation, requires a data length for data transfer no larger than 64 transfers. The number of bytes=transfer length.times.byte width. Each data transfer is governed by a protocol that mandates the data transfer have three distinct phases: an address phase (which includes the connecting to the bus and the address of the data), a data phase (which includes the transmission of the data from the source address to the destination address), and a disconnect phase (which includes the disconnection from the bus). Each phase of the protocol must be completed before another data transfer may take place. Due to local bus limitations, any block data transfer greater than the architectural standard of the local bus (in this embodiment the Hbus standard of 64 bytes) would be required to be split up into a plurality of block data transfers each of a size equal to the maximum amount permitted within the architectural standard. Therefore, any large block data transfer will be slowed by the extra time associated with the plurality of smaller block data transfers required to transfer the large block of data. Therefore, large data transfers proceed slowly since a large block of data must be broken into smaller sections and transferred separately.
Each data transfer must endure the transfer protocol of: address, data, and disconnect. "Protocol overhead" timing is the time that elapses during the address phase, data phase, and disconnection phase of each data transfer when attempting to transfer a large block of data. The "protocol overhead" timing suffered during block data transfers was anticipated by Futurebus+ architecture standard developers and a binary signal designated "MORE" was provided in the architectural scheme to deal with the "protocol overhead" timing issue. The "MORE" signal overrides the standard bus protocol and allows block data transfers greater than the maximum amount permitted within the local bus architectural standard to be transferred at one time. Therefore, the block data transfer would have only one address phase, one data phase, and one disconnect phase. The control of the "MORE" signal has been left to individual chip designers to manipulate as desired.
An obvious method of controlling the "MORE" signal within Futurebus+ architecture standards uses a direct memory access (DMA) controller to control the "MORE" signal to implement block data transfers. However, DMA controllers are highly complex circuit components that require significant die space when integrating onto bus controllers. They also increase system costs if a separate "DMA" controller chip is placed on a computer board. Therefore, other methods are needed to efficiently and inexpensively manipulate the "MORE" signal provided in the Futurebus+ architecture standard.
It is accordingly an object of the invention to efficiently and inexpensively control "protocol overhead" timing in bus structures. It is a further object of this invention to efficiently control the "MORE" signal in bus structures adopting the Futurebus+ architecture standard.
Other objects and advantages of the invention will become apparent to those of ordinary skill in the art having reference to the following specification together with the drawings herein.